home *** CD-ROM | disk | FTP | other *** search
-
-
-
- DDDDBBBBMMMM((((3333BBBB)))) DDDDBBBBMMMM((((3333BBBB))))
-
-
-
- NNNNAAAAMMMMEEEE
- dbm: dbminit, dbminit64, dbmclose, dbmclose64, fetch, fetch64, store,
- store64, delete, delete64, firstkey, firstkey64, nextkey, nextkey64 -
- data base subroutines
-
- SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
- ####iiiinnnncccclllluuuuddddeeee <<<<ddddbbbbmmmm....hhhh>>>>
-
- ttttyyyyppppeeeeddddeeeeffff ssssttttrrrruuuucccctttt {{{{
- cccchhhhaaaarrrr ****ddddppppttttrrrr;;;;
- iiiinnnntttt ddddssssiiiizzzzeeee;;;;
- }}}} ddddaaaattttuuuummmm;;;;
-
- iiiinnnntttt ddddbbbbmmmmiiiinnnniiiitttt((((ccccoooonnnnsssstttt cccchhhhaaaarrrr ****ffffiiiilllleeee))));;;;
-
- iiiinnnntttt ddddbbbbmmmmiiiinnnniiiitttt66664444((((ccccoooonnnnsssstttt cccchhhhaaaarrrr ****ffffiiiilllleeee))));;;;
-
- vvvvooooiiiidddd ddddbbbbmmmmcccclllloooosssseeee((((vvvvooooiiiidddd))));;;;
-
- vvvvooooiiiidddd ddddbbbbmmmmcccclllloooosssseeee66664444((((vvvvooooiiiidddd))));;;;
-
- ddddaaaattttuuuummmm ffffeeeettttcccchhhh((((ddddaaaattttuuuummmm kkkkeeeeyyyy))));;;;
-
- ddddaaaattttuuuummmm ffffeeeettttcccchhhh66664444((((ddddaaaattttuuuummmm kkkkeeeeyyyy))));;;;
-
- iiiinnnntttt ssssttttoooorrrreeee((((ddddaaaattttuuuummmm kkkkeeeeyyyy,,,, ddddaaaattttuuuummmm ccccoooonnnntttteeeennnntttt))));;;;
-
- iiiinnnntttt ssssttttoooorrrreeee66664444((((ddddaaaattttuuuummmm kkkkeeeeyyyy,,,, ddddaaaattttuuuummmm ccccoooonnnntttteeeennnntttt))));;;;
-
- iiiinnnntttt ddddeeeelllleeeetttteeee((((ddddaaaattttuuuummmm kkkkeeeeyyyy))));;;;
-
- iiiinnnntttt ddddeeeelllleeeetttteeee66664444((((ddddaaaattttuuuummmm kkkkeeeeyyyy))));;;;
-
- ddddaaaattttuuuummmm ffffiiiirrrrssssttttkkkkeeeeyyyy((((vvvvooooiiiidddd))));;;;
-
- ddddaaaattttuuuummmm ffffiiiirrrrssssttttkkkkeeeeyyyy66664444((((vvvvooooiiiidddd))));;;;
-
- ddddaaaattttuuuummmm nnnneeeexxxxttttkkkkeeeeyyyy((((ddddaaaattttuuuummmm kkkkeeeeyyyy))));;;;
-
- ddddaaaattttuuuummmm nnnneeeexxxxttttkkkkeeeeyyyy66664444((((ddddaaaattttuuuummmm kkkkeeeeyyyy))));;;;
-
- DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
- NNNNooootttteeee:::: tttthhhheeee ddddbbbbmmmm lllliiiibbbbrrrraaaarrrryyyy hhhhaaaassss bbbbeeeeeeeennnn ssssuuuuppppeeeerrrrsssseeeeddddeeeedddd bbbbyyyy nnnnddddbbbbmmmm((((3333BBBB)))),,,, aaaannnndddd iiiissss nnnnoooowwww
- iiiimmmmpppplllleeeemmmmeeeennnntttteeeedddd uuuussssiiiinnnngggg nnnnddddbbbbmmmm.... These functions maintain key/content pairs in a
- data base. The ddddbbbbmmmm functions will handle very large (a billion blocks)
- databases and will access a keyed item in one or two file system
- accesses. The ddddbbbbmmmm66664444 routines are identical to their ddddbbbbmmmm counterparts
- except that they can be used to operate on data bases larger than 2
- Gigabytes.
-
-
-
-
-
-
- PPPPaaaaggggeeee 1111
-
-
-
-
-
-
- DDDDBBBBMMMM((((3333BBBB)))) DDDDBBBBMMMM((((3333BBBB))))
-
-
-
- _K_e_ys and _c_o_n_t_e_n_ts are described by the _d_a_t_u_m typedef. A _d_a_t_u_m specifies
- a string of _d_s_i_z_e bytes pointed to by _d_p_t_r. Arbitrary binary data, as
- well as normal ASCII strings, are allowed. The data base is stored in
- two files. One file is a directory containing a bit map and has `.dir'
- as its suffix. The second file contains all data and has `.pag' as its
- suffix.
-
- Before a database can be accessed, it must be opened by _d_b_m_i_n_i_t. At the
- time of this call, the files _f_i_l_e....ddddiiiirrrr and _f_i_l_e....ppppaaaagggg must exist. (An empty
- database is created by creating zero-length `.dir' and `.pag' files.)
-
- Once open, the data stored under a key is accessed by _f_e_t_c_h and data is
- placed under a key by _s_t_o_r_e. A key (and its associated contents) is
- deleted by _d_e_l_e_t_e. A linear pass through all keys in a database may be
- made, in an (apparently) random order, by use of _f_i_r_s_t_k_e_y and _n_e_x_t_k_e_y.
- _F_i_r_s_t_k_e_y will return the first key in the database. With any key _n_e_x_t_k_e_y
- will return the next key in the database. The following code will
- traverse the data base:
-
- for (key = firstkey(); key.dptr != NULL; key = nextkey(key))
-
-
- DDDDIIIIAAAAGGGGNNNNOOOOSSSSTTTTIIIICCCCSSSS
- All functions that return an _i_n_t indicate errors with negative values. A
- zero return indicates ok. Routines that return a _d_a_t_u_m indicate errors
- with a null (0) _d_p_t_r.
-
- Some error conditions will set _e_r_r_n_o. These are: EEEENNNNOOOOMMMMEEEEMMMM:::: runtime memory
- allocation failed; EEEEPPPPEEEERRRRMMMM:::: file permissions don't match the process
- euid/egid permissions; EEEEIIIINNNNVVVVAAAALLLL:::: key+data sizes for _d_b_m__s_t_o_r_e exceed the
- internal block size; EEEEFFFFBBBBIIIIGGGG:::: hash table overflow would cause the maximum
- dbm file size to be exceeded.
-
-
- SSSSEEEEEEEE AAAALLLLSSSSOOOO
- ndbm(3B) and Berkeley db: dbopen(3)
-
- BBBBUUUUGGGGSSSS
- _D_p_t_r pointers returned by these subroutines point into static storage
- that is changed by subsequent calls.
-
- _d_b_m databases may not be portable across machines with different
- alignment restrictions or different byte sexes.
-
- _D_p_t_r pointers returned by these subroutines point into possibly non word
- aligned storage. You cannot assume that you can cast the _D_p_t_r pointer
- into an arbitrary data type and dereference it. This is a general rule
- in ANSI-C rather than _d_b_m specific, but users often hit it while using
- _d_b_m.
-
-
-
-
-
-
- PPPPaaaaggggeeee 2222
-
-
-
-
-
-
- DDDDBBBBMMMM((((3333BBBB)))) DDDDBBBBMMMM((((3333BBBB))))
-
-
-
- The sum of the sizes of a key/content pair must not exceed the internal
- block size minus the _d_b_m small book-keeping overhead (currently _PBLKSIZ
- - 6 = 1018 bytes). Moreover all key/content pairs that hash together
- must fit on a single block. For a dbm-like implementation with much less
- size limitations, check out ddddbbbbooooppppeeeennnn((((3333)))) (Berkeley DB).
-
- _S_t_o_r_e will return an error in the event that a disk block fills with
- inseparable data.
-
- _D_e_l_e_t_e does not physically reclaim file space, although it does make it
- available for reuse.
-
- The order of keys presented by _f_i_r_s_t_k_e_y and _n_e_x_t_k_e_y depends on a hashing
- function, not on anything interesting.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PPPPaaaaggggeeee 3333
-
-
-
-